Date: Wed,  6 Jan 93 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #6
To: packet-radio


Packet-Radio Digest         Wed,  6 Jan 93       Volume 93 : Issue    6

Today's Topics:
                     access to KA(Q tcp/ip code?
                       Atari 800XL for packet ?
                         AX.25 streams driver
                        MFJ-1274 & TAPR 1.1.8a
                            SLIP - What is
SLIP - What is (answer) - NOS versions, 'dialer', SLIP timeout., finger (questions) Thanks! (2 msgs)
                         TAPR Annual Meeting
                        Wormhole - What is it?

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue, 5 Jan 1993 15:02:00 GMT
From: newsgate.watson.ibm.com!yktnews!admin!sernews!news@uunet.uu.net
Subject: access to KA(Q tcp/ip code?
To: packet-radio@ucsd.edu

In <1ia2rcINNna7@sixgun.East.Sun.COM> gilly@gilly.East.Sun.COM (Bob Gilliland SE Cloumbia, Md Office) writes:
>From where on the Internet can I download Phil's, KA(Q, cuurent release of tcp/ip code?
>Anonymous ftp I hope...
>
>Thanks for your help,
>
>Bob  K3TCT

The UCSD.EDU ftp server has all the latest TCP/IP code. KA9Q JUST 
posted his latest version yesterday. s930104.zip is in the
/hamradio/packet/tcpip/ka9q directory. The other flavors of NOS are in
their own directories in the /hamradio/packet/tcpip directory.

73's  de  Jack - kf5mg
AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.na - (817) 962-4409
AMPRnet         -  kf5mg@kf5mg.ampr.org       - 44.28.0.14
Internet        -  kf5mg@vnet.ibm.com

------------------------------

Date: 5 Jan 93 20:57:28 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!yale.edu!ira.uka.de!Sirius.dfn.de!zam103!djukfa11!iff118@network.UCSD.EDU
Subject: Atari 800XL for packet ?
To: packet-radio@ucsd.edu

As SP operates its first digipeater with links to abroad,
I have  been asked, if anybody has experience with packet
radio on old Atari. In Poland they are still popular and
available.
Tank you in advance

Piotr, DH0KPS, ex SP6 MLD

------------------------------

Date: Tue, 5 Jan 1993 16:24:31 GMT
From: usc!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!inetnode.austin.ibm.com!miltonm@network.UCSD.EDU
Subject: AX.25 streams driver
To: packet-radio@ucsd.edu

I seem to rember seeing a streams driver to send AX.25 packets out from
unix systems.   However, I can't seem to locate the code.   The system
will be a 386 running Interactive Unix System V version 3.

I would apreciate any pointers.

Thanks,
milton

------------------------------

Date: 6 Jan 93 06:00:06 GMT
From: news-mail-gateway@ucsd.edu
Subject: MFJ-1274 & TAPR 1.1.8a
To: packet-radio@ucsd.edu

Jim,
I can't help you with the 2400 bps modem part of your problem, but I 
expect that if your 1274 was running 1.1.4, it only has 16k of RAM.  
1.1.5 and later require 32K, so you will have to upgrade.  I think the 
instructions are in the 1274 manual, and the chips and instructions are 
also available from both MFJ and TAPR.  The problem with the 2400 bps 
modem is entirely unrelated to the firmware, I am sure.

Bob

Bob Nielsen W6SWE       
ax.25: w6swe@wb7tpy.az.usa.na    Internet: rnielsen@tapr.ampr.org
amateur IP: 44.124.12.16         CIS: 71540,2364

------------------------------

Date: 5 Jan 1993 16:50:21 GMT
From: ucsd.edu!brian@network.UCSD.EDU
Subject: SLIP - What is
To: packet-radio@ucsd.edu

SLIP is Serial Line IP.  It's a trivial protocol for encapsulating an IP
frame on a serial line to do cheap IP networking.  KISS is the same
thing for AX.25.  Details in the docs in the hamradio/packet collection
on UCSD.EDU.
	- Brian

------------------------------

Date: Tue, 5 Jan 1993 16:18:53 GMT
From: usc!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!inetnode.austin.ibm.com!miltonm@network.UCSD.EDU
Subject: SLIP - What is (answer) - NOS versions, 'dialer', SLIP timeout., finger (questions) Thanks!
To: packet-radio@ucsd.edu

In article <9301050143.AA00731@westport.trirex.com> bmehlman@trirex.COM (Ben Mehlman) writes:
>I am trying to set up dial-in and dial out SLIP on my KA9Q NOS box.   
>On the dial in, I have one problem to solve, which is that I want the  
>modem to hang up on the caller if there is no activity on the port  
>for a few minutes.  I don't think the NOS is equipped to do this.  My  
>solution so far is to bastardize the 'dialer' code to create a  
>'watcher'.  The watcher watches for data transmissions and carrier  
>status on a port.  If CD stays true for XX time without any activity,  
>it (depending on how ambitious I get) drops DTR fora couple of  
>seconds or executes a hangup script.
>
>I was wondering: has anyone else has approached this problem, and how  
>did you solve (or fail to solve) it?
>

My understanding is Phil Karn has done it.  He released the code in June,
although the initial release had a "peter waiting on paul waiting on peter"
syndrome.   I don't rember the fix.  Phil also just released a new
set of code today (yesterday?) on ucsd.  Since there were several problems
with the June release (Phil called it beta code; it was somewhere between
alpha and beta quality), none of the other enhancers picked up the code,
opting to stick with the known 12/21/91 release.

>
>Anyway, there are two things I am trying to accomplish re dialing: 
>
>
>1 - Keep a line up, ie dial a connection to another site and keep it  
>going, redialing automatically if the link should drop.  The version  
>of 'dialer' described in my docs seems like it is written  
>specifically for this purpose.
>

This is the code in the 12/21/91 release and derivatives (PA0GRI, 
WG7J, etc).

>2 - Demand dial a line, ie when I try to send a packet through that  
>port, if the connection is down it dials.  If the connection should  
>be terminated (ie ma bell gives up or the other side times out), my  
>side does nothing unless another packet is sent.  I was also thinking  
>another that a timeout on my end would be nice, ie set a maximum time  
>that my end will keep the connection going in the absence of traffic.
>

Phil has done the above.  According to his last post, the latest
code is split into up, down, and ring scripts so he can share
his modem line with his autoswitch fax!

>Another question:  What is the difference between the current KA9Q  
>release of NOS and the version maintained by PA0GRI?
>

PA0GRI added several usablity features and started mailbox enhancements.
WG7J took that code and turned it into something close to a full service
bbs, fixing forwarding, starting finger, etc).  WG7J is at least at version
1.07b.

>Re: finger and fingerd
>I am having a problem with finger where I can finger the NOS box from  
>my unix box, and get the system info and a list of all 'users' ie  
>files in /nos/cfg/finger (on my system \nos\cfg is passed to  
>net.exe).  However, when I try to finger a particular user it says  
>'user not known'.  I was wondering if I am doing something really  
>dumb.  I also have those same users listed in my ftpusers file.
>
does the file have a .txt extension?

>In the source I have, you cannot finger someone on your own machine.   
>I was wondering if there is any reason why one couldn't modify finger  
>to assume the local hostname where none is supplied.  

No, you can connect to a local socket.   For it to work without a
domain.txt for the hostname, use the loopback address (127.0.0.1).

>
>Thanks and 73, 
>
>
>Ben KB2ERP

Your welcome,

Milton Miller
KB5TKF
miltonm@inetnode.austin.ibm.com

"These statements are made by my self and not IBM.  They may or may not
reflect the views of IBM."

------------------------------

Date: Wed, 6 Jan 1993 09:13:32 GMT
From: qualcom.qualcomm.com!servo.qualcomm.com!karn@network.UCSD.EDU
Subject: SLIP - What is (answer) - NOS versions, 'dialer', SLIP timeout., finger (questions) Thanks!
To: packet-radio@ucsd.edu

In article <C0E2nH.uqv@austin.ibm.com> miltonm@inetnode.austin.ibm.com (Milton Miller) writes:
>My understanding is Phil Karn has done it.  He released the code in June,
>although the initial release had a "peter waiting on paul waiting on peter"
>syndrome.   I don't rember the fix.  Phil also just released a new
>set of code today (yesterday?) on ucsd.  Since there were several problems
>with the June release (Phil called it beta code; it was somewhere between
>alpha and beta quality), none of the other enhancers picked up the code,
>opting to stick with the known 12/21/91 release.

Actually, other than adding the "answer" script, fixing a few minor
bugs and making some internal changes to allow dialing on media other
than asynch lines, I really haven't done anything to the dialer code
in quite some time. I use it constantly (right now, as a matter of
fact) and it is pretty solid.

>>1 - Keep a line up, ie dial a connection to another site and keep it  
>>going, redialing automatically if the link should drop.  The version  
>>of 'dialer' described in my docs seems like it is written  
>>specifically for this purpose.
>
>This is the code in the 12/21/91 release and derivatives (PA0GRI, 
>WG7J, etc).

Yes, this is what the original dialer did. I ran it for years when I
lived in New Jersey. Even though I never heard a peep from NJ Bell
about the continuous 1 Erlang load on my second phone line, I always
felt a little guilty about it. However, to get the free local call
into Bellcore I had to dial into a location other than the one where I
worked and hop back over a brain-damaged Micom terminal network. This
was such a slow and painful process (and one I could not easily initiate
in the other direction) that I opted to keep the line nailed up
continuously, with the call always placed from home.

However, now that I live in San Diego and am a local phone call away
from Qualcomm's netblazer, I decided to do the job right and bring
up the link only when it's needed.

>>2 - Demand dial a line, ie when I try to send a packet through that  
>>port, if the connection is down it dials.  If the connection should  
>>be terminated (ie ma bell gives up or the other side times out), my  
>>side does nothing unless another packet is sent.  I was also thinking  
>>another that a timeout on my end would be nice, ie set a maximum time  
>>that my end will keep the connection going in the absence of traffic.
>
>Phil has done the above.  According to his last post, the latest
>code is split into up, down, and ring scripts so he can share
>his modem line with his autoswitch fax!

Yup, this is exactly how the code works, even down to the single try
per packet. When you send a packet and the link is down, it is held.
If the dial attempt succeeds, the packet (and any others that have
arrived in the send queue) are sent. If the attempt fails, the packet
that caused it is dropped. If there's another packet waiting in
the queue, another attempt is immediately made. Otherwise it waits
for another packet to arrive before it does anything.

I do it this way to avoid any built-in "retry" timeouts in the dialer
code. I instead rely on TCP retransmission backoffs to time each
successive call attempt. I used to redial repeatedly from a single
packet with my own built-in backoff, but this was much less
satisfactory because once you got into that mode, there was no
external way to control it. With the new way I can manually force
continuous redialing by just starting up a repeating ping session
across the path.

I note that the internal hooks are now there to let you implement
"demand dialing" of AX.25 connections if you so desire, although I
don't see much point since an AX.25 "connection" doesn't really cost
anything but a little RAM at each end to keep open and idle.

>No, you can connect to a local socket.   For it to work without a
>domain.txt for the hostname, use the loopback address (127.0.0.1).

Right. This is a convention I picked up from BSD UNIX. You can always
talk to yourself by using IP address 127.0.0.1, regardless of any
other addresses you may have. There's a built-in "pseudo-interface"
called the "loopback" interface with this address.

Phil

------------------------------

Date: 6 Jan 93 05:30:04 GMT
From: news-mail-gateway@ucsd.edu
Subject: TAPR Annual Meeting
To: packet-radio@ucsd.edu

TAPR 1993 Annual Meeting
------------------------

The Annual Meeting of Tucson Amateur Packet Radio will be held on the
weekend of March 6th and 7th, 1993 at the Best Western Inn at the
Airport, 7060 S. Tucson Blvd, Tucson, Arizona, adjacent to Tucson
International Airport.  

In addition to the usual presentations of the latest and greatest
developments in packet radio, TAPR will host a workshop on digital signal
processing (DSP) for radio amateurs.  This workshop, to be conducted by
Jon Bloom, KE3Z, ARRL Senior Engineer, is designed to teach the
fundamentals of digital signal processing.  The target students are radio
amateurs who understand the basics of complex (modulated) signals and are
familiar with computer programming.  The course is intended to bridge the
gap between these two subjects, with the result that the student will be
able to begin programming DSP applications almost immediately.  The
student's math background should include algebra and trigonometry.

The topics covered by the presentation include:
     Discrete-time systems
     Sampling theory
     Digital filters
     Signal generation and detection
     Discrete and Fast Fourier Transforms, with applications
     Applications of DSP to Amateur Radio
     Development tools
     Review of available literature

We are expecting to have the traditional "pizza bash" and other informal
activities on Friday night, March 5, with the meeting all day Saturday,
March 6 and the DSP workshop on Sunday, March 7.  Registration for the
Saturday meeting is $15.00, including a buffet luncheon.  There will also be 
a $5.00 registration fee for the DSP workshop on Sunday to cover the cost of
printed workshop materials.  A steak dinner on Saturday night will be 
available for $13.95.  TAPR will have a hospitality suite where you
can gather informally, join TAPR or purchase kits and software.  The meetings
will run from 9:00 a.m. to 5:00 p.m. both days.

A block of rooms has been reserved at the special rate of $53.00 per
night, single or double occupancy, including full American breakfast and
happy hour reception.  For reservations, call the Inn at the Airport at
1-800-772-3847, or in Arizona at 602-746-0271, FAX 602-889-7391 (mention
TAPR to get this rate).

If you are planning to attend or have a project you would like to present
at the meeting, please call or write the TAPR office and let us know.  We
also would like to know if you are planning to attend the DSP workshop,
so sufficient materials will be available.  To have your paper included
in the printed proceedings of the meeting, camera-ready copy should be
submitted to TAPR no later than February 19, 1993.  For further
information, contact the TAPR office.

Tucson Amateur Packet Radio
P.O. Box 12925
Tucson, AZ 85732-2925
602-749-9479 (10 a.m. - 3 p.m., Tue-Fri)
FAX 602-749-5636

Bob Nielsen W6SWE       
ax.25: w6swe@wb7tpy.az.usa.na    Internet: rnielsen@tapr.ampr.org
amateur IP: 44.124.12.16         CIS: 71540,2364

------------------------------

Date: 5 Jan 93 20:49:13 GMT
From: olivea!sgigate!odin!jerber.sandiego.sgi.com!jerryb@ames.arpa
Subject: Wormhole - What is it?
To: packet-radio@ucsd.edu

In article <1993Jan3.042000.11741@spatula.rent.com>, ahm@spatula.rent.com
(Andreas Meyer) writes:
|> In rec.radio.amateur.packet, p653663@austin.lockheed.com (p653663)
|> writes:
|> > Sure would appreciate some docs on the wormholes or whatever
|> > they are called. What are they and how do you use them.
|> 
|> I suspect a "documented wormhole" would be called a "gateway". :-)
|> 
|> Andy
|> -- 
|>  Andreas Meyer, N2FYE      ahm@spatula.rent.com     "Been there. Did
|> that."

Now I know nothing about wormholes except for what was in a recent
newspaper article that discussed them briefly.

It's a VERY theoretical/hypothetical method of travel through space that
allows very rapid/instantaneous travel via these so-called 'wormholes' to
distant (light years of distance) places. It's said that this method, if it
can be figured out enough to use, would allow some forms of spacetravel to
be almost instananeous.    

This theory is beyond my understanding, but they claim it has serious
scientific validity.

Please no flames... I'm no trekky, and have no belief in the above one way
or another, just relaying a tiny bit of what the newspaper article said.

Bottom line?  Don't look for a wormhole to be available anywhere soon.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jerry Bransford			
Silicon Graphics
(619) 546-0409
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

------------------------------

Date: Tue, 5 Jan 1993 20:00:08 GMT
From: das.wang.com!wang!tegra!vail@uunet.uu.net
To: packet-radio@ucsd.edu

References <1993Jan2.184109.13079@mnemosyne.cs.du.edu>, <eNTRwB1w164w@ham.almanac.bc.ca>, <1993Jan4.144520.19597@ultb.isc.rit.edu>
Subject : Re: Who do repeater coordinators represent?



In article <1993Jan4.144520.19597@ultb.isc.rit.edu> cep4478@ultb.isc.rit.edu (C.E. Piggott ) writes:


   In article <eNTRwB1w164w@ham.almanac.bc.ca> emd@ham.almanac.bc.ca writes:
   >and that in many areas, all available repeater frequencies were assigned 
   >BEFORE Packet became popular. There are several possible solutions here. 
   >1. Persuade some local group to "give-up" a voice repeater frequency so
   >   you can put up a packet repeater.

   Statements like "I heard packet works better through a repeater" concern
   me (not that you said that - I've just heard it before).  One of the
   potential strengths of packet is as a distributed, redundant system.
   Adding a repeater greatly reduces collisions, but at a significant
   expense:

I don't understand why you think these are problems:

	   - the repeater is a single point-of-failure, and
		   many people will not be able to or know
		   how to operate without it when the repeater
		   dies

Making a better system will encourage stupidity?

	   - repeater coverage rarely stays localized.  After
		   a while, a better antenna, more power, etc.
		   and you wind up with a wide-coverage packet
		   repeater that is jammed up.

Making a useful system will make people want to use it?

I don't see either of your points as being problems.  In fact if it
were to become a problem then it just points out the need for *more*
digital repeaters.

Getting back to the original topic we can discuss the problems of
getting coordination since the repeater coordinators consider it
packet and not eligible for the same protection as their repeaters.

jv

 _____
|     | Johnathan Vail     vail@tegra.com     (508) 663-7435
|Tegra| jv@n1dxg.ampr.org    N1DXG@448.625-(WorldNet)
 -----  MEMBER: League for Programming Freedom (league@prep.ai.mit.edu)

------------------------------

Date: 5 Jan 1993 22:03:14 GMT
From: usc!cs.utexas.edu!tamsun.tamu.edu!cs.tamu.edu!kurt@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <eNTRwB1w164w@ham.almanac.bc.ca>, <1993Jan4.144520.19597@ultb.isc.rit.edu>, <C0ECw9.or@tegra.com>
Subject : Re: Who do repeater coordinators represent?

In article <C0ECw9.or@tegra.com>, vail@tegra.com (Johnathan Vail) writes:
|> 
|> I don't see either of your points as being problems.  In fact if it
|> were to become a problem then it just points out the need for *more*
|> digital repeaters.

Amen!

|> Getting back to the original topic we can discuss the problems of
|> getting coordination since the repeater coordinators consider it
|> packet and not eligible for the same protection as their repeaters.

True.  Coordinators have the attitude "if it buzzes, we don't do it."
However, as a wise person observed, "Packet people don't know s**t about
radios; Radio people don't know s**t about packet."  In the general case,
regrettably true.  Packet folks aren't experienced enough to deal with
coordination lore.  AND they don't consider full-duplex regenerators
(aka packet repeaters) as repeaters, because some of the bits get changed.
They really don't but that's a nit.  I maintain that there is a signal
that is being received, and the information is being retransmitted in
real-time.  THAT's a repeater, and coordinators should be able to 
coordinate those, because it's the case that the frequencies need to be
(Oh Gawd, they'll pounce on this...) "protected" by coordination.
Simplex (standard digipeating) packet systems should NOT be coordinated,
at least in terms of spectrum.  Packet groups, if they are stupid enough
to get into it, should coordinate that.  There's coordination, then there's
coordination.

In the pure sense, repeater coordinators should not represent ANYBODY.
They are a central, neutral, organ that should be used to COORDINATE
the usage of spectrum, under the "accepted standards".  The group that
decides the "accepted standards" consists of the folks that represent
whatever factions that obtain.  Rather like the Geneva Convention, I'd
venture.

Vox Populi, Vox Dei - Latin for "How did we get into THIS mess?"
                       ..Name that author...


-- 
Kurt Freiberger, wb5bbw	  kurt@cs.tamu.edu   409/847-8607  fax:409/847-8578
Dept. of Computer Science, Texas A&M University      DoD #264: BMW R80/7 pilot
"We preserve our freedom using three boxes: ballot, jury, and cartridge."
      *** Not an official document of Texas A&M University ***

------------------------------

Date: Tue, 5 Jan 1993 19:28:20 GMT
From: qualcom.qualcomm.com!servo.qualcomm.com!karn@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <1993Jan4.170301.16175@sernews.raleigh.ibm.com>, <C0DC8G.CF5@zero.com>, <1icen4INN2dg@newz.ens.tek.com>
Subject : Re: Wormhole - What is it?


The term "wormhole" as applied to amateur packet radio (it was
obviously borrowed from science fiction) refers to a link in an
amateur network that uses non-amateur facilities such as a commercial
satellite link, leased line, the Internet, etc.

A wormhole usually encapsulates the amateur packet protocol within
those of the non-ham network in such a way that the non-ham network's
internal details are hidden from the ham user. The two amateur nodes
on the ends of the wormholes appear to be immediate neighbors, even
though there may be much distance and a very complex (non ham) network
between them. Hence the apt allusion to the sci-fi concept of a wormhole.

The allusion is even more apt when you consider that both types of
wormholes are usually provided by fantastically advanced beings with
vastly superior technologies who have a difficult time understanding
the motives and makeup of the primitive corporeal beings that use
them. :-)

Phil

------------------------------

Date: 5 Jan 1993 16:58:11 GMT
From: news.tek.com!cascade.ens.tek.com!ronk@uunet.uu.net
To: packet-radio@ucsd.edu

References <1993Jan3.042000.11741@spatula.rent.com>, <1993Jan4.170301.16175@sernews.raleigh.ibm.com>, <C0DC8G.CF5@zero.com>
Reply-To : Ron.C.Kirkpatrick@tek.com
Subject : Re: Wormhole - What is it?

In article <C0DC8G.CF5@zero.com>, steve@zero.com (Steve Urich) writes:
|> In <1993Jan4.170301.16175@sernews.raleigh.ibm.com>, JGRASS@VNET.IBM.COM writes:
|> [...]
|> >   A wormhole is a long distance link between two stations using the
|> >same protocol. A gateway converts one protocol to another. A wormhole
|> 	I'd say, I seen one in action today on the new startrek series
|> 	Deep Space 9. It gets you right into the Gamma quadrant in
|> 	about 30 secs pretty good eh :-). 

Today??? I don't get to see DS9 until Thursday! (I must be caught in a time
vortex.)

-- 
Ron Kirkpatrick
Tektronix, Inc
News Administrator
503-627-6707

------------------------------

Date: Wed, 6 Jan 1993 09:32:18 GMT
From: qualcom.qualcomm.com!servo.qualcomm.com!karn@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <1993Jan2.184109.13079@mnemosyne.cs.du.edu>, <eNTRwB1w164w@ham.almanac.bc.ca>, <1993Jan4.144520.19597@ultb.isc.rit.edu>
Subject : Re: Who do repeater coordinators represent?

In article <1993Jan4.144520.19597@ultb.isc.rit.edu> cep4478@ultb.isc.rit.edu (C.E. Piggott ) writes:
>Statements like "I heard packet works better through a repeater" concern
>me (not that you said that - I've just heard it before).  One of the
>potential strengths of packet is as a distributed, redundant system.
>Adding a repeater greatly reduces collisions, but at a significant
>expense:
>
>	- the repeater is a single point-of-failure, and
>		many people will not be able to or know
>		how to operate without it when the repeater
>		dies
>	- repeater coverage rarely stays localized.  After
>		a while, a better antenna, more power, etc.
>		and you wind up with a wide-coverage packet
>		repeater that is jammed up.

Deja vu warning...

I happen to agree with this. Using repeaters to reduce collisions
*does* involve a significant opportunity cost. Unfortunately, the
alternative techniques to "do it right" are still not yet known in the
amateur service. These include:

1. Spread spectrum, which creates a channel that degrades more
gracefully with multiple simultaneous transmitters than does a
narrowband channel.

2. Strong forward error correction coding. By decreasing the required
signal-to-noise(interference) ratio, this enhances the ability of
spread spectrum to tolerate multiple simultaneous transmitters on a
channel. And by reducing the necessary transmitter power to sustain a
link, it also reduces interference to other receivers.

3. Automatic transmitter power control so you never use more power
than is actually necessary to reach a particular node.

4. Automatic routing algorithms with link metrics based on
power/interference estimates so that paths are chosen on the basis of
their minimum impact on overall system capacity. I.e., you would
choose a path of many closely spaced nodes over a few widely spaced
nodes because the much lower power required at each hop would more
than make up for the increased number of hops.

Phil

------------------------------

Date: Tue, 5 Jan 1993 15:09:58 GMT
From: swrinde!emory!kd4nc!ke4zv!gary@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <1993Jan2.184109.13079@mnemosyne.cs.du.edu>, <eNTRwB1w164w@ham.almanac.bc.ca>, <1993Jan4.144520.19597@ultb.isc.rit.edu>
Reply-To : gary@ke4zv.UUCP (Gary Coffman)
Subject : Packet Repeaters was(Re: Who do repeater coordinators represent?)

In article <1993Jan4.144520.19597@ultb.isc.rit.edu> cep4478@ultb.isc.rit.edu (C.E. Piggott ) writes:
>
>Statements like "I heard packet works better through a repeater" concern
>me (not that you said that - I've just heard it before).  One of the
>potential strengths of packet is as a distributed, redundant system.
>Adding a repeater greatly reduces collisions, but at a significant
>expense:
>
>	- the repeater is a single point-of-failure, and
>		many people will not be able to or know
>		how to operate without it when the repeater
>		dies
>
>	- repeater coverage rarely stays localized.  After
>		a while, a better antenna, more power, etc.
>		and you wind up with a wide-coverage packet
>		repeater that is jammed up.

That's true, but it's also true that most packet groups are sparse
enough that high site nodes are required *anyway* to maintain connectivity, 
and they also serve as a single point failure *and* as a magnet for congestion.
Therefore these arguments apply equally to them. The fact is that a repeater 
just works much better than a high site simplex node for packet.

If you stick with just home stations and multi-hop links, then you're
generating even more congestion since each packet is transmitted multiple
times. Home sites are unfortunately not engineered to be non-interfering
cells. And one home station shutting down can fragment the network if it
is the only link between two subnets. That's very common in rough terrain
with sparse networks. The channel delay of multiple hop transmissions also 
turns a slow service into an infuriatingly slower service.

Repeaters for packet should best be thought of as large, controlled
coverage cells. Linked by a high speed backbone, they offer high
thruput while minimizing the interference common to simplex networks.

Gary
-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary      
Lawrenceville, GA 30244     |                     | emory!ke4zv!gary@gatech.edu
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